home *** CD-ROM | disk | FTP | other *** search
/ CD ROM Paradise Collection 4 / CD ROM Paradise Collection 4 1995 Nov.iso / program / swagg_m.zip / GRAPHICS.SWG / 0065_Textures.pas < prev    next >
Pascal/Delphi Source File  |  1994-01-27  |  7KB  |  198 lines
  1.  
  2. {
  3. ANDREW FORT
  4. > That's fast, but that's just one bitmap. I really need to sit down and
  5. > optimize my texture mapper...
  6.  
  7. > You have to use 386 instructions cuz 32-bit division is way too slow
  8. > otherwise. I'd have to see the code to tell if it's efficient or not. It's
  9. > a simple algorithm, just figuring out where in the bitmap to start and
  10. > what the step value is for each scan line is the hard part. Then just do
  11. > 320 pixels real quick... don't worry, cuz with 256x256 bitmaps, everything
  12. > just works itself out real nice.
  13.  
  14. yes i realize it works out real nice with 256x256 bitmaps, because you can
  15. shift/carry or whatever to get the particular point in the bitmap you want
  16. easily.
  17.  
  18. yes it uses 32 bit instructions, but since it's so short, it's not a problem
  19. coding it in BASM.. and here it is:
  20.  
  21. ** this code was written by The Faker of Aardvark **
  22. }
  23.  
  24. PROCEDURE PutTexture(IncX, IncY : Integer; P : Pointer);
  25. VAR
  26.   Y, PosX,
  27.   PosY,
  28.   PX, PY : Integer;
  29. BEGIN
  30.   PosX := -(ScreenX SHR 1) * IncX;   { ScreenX,-Y are size of screen    }
  31.   PosY := -(ScreenY SHR 1) * IncY;   { PosX,y set so rotation is around }
  32.   FOR Y := 0 TO ScreenY-1 DO       { the middle (of 'p')              }
  33.   BEGIN
  34.     PX := PosX;   { PosX,-Y is updated every line, PX,-y derived   }
  35.     PY := PosY;
  36.     ASM
  37.       push ds
  38.       mov  ax, 0a000h
  39.       mov  es, ax
  40.       mov  ax, y
  41.       xchg al, ah
  42.       mov  di, ax
  43.       shr  di, 2
  44.       add  di, ax
  45.       lds  si, p   { in P there should be a 256x256 bitmap }
  46.       mov  cx, screenx shr 1
  47.       cld
  48.       mov  ax, incx
  49.       shl  eax, 16
  50.       mov  ax, incy
  51.       mov  esi, eax
  52.       mov  dx, px
  53.       shl  edx, 16
  54.       mov  dx, py
  55.      @1:
  56.       add  edx, esi
  57.       mov  ebx, edx
  58.       shr  ebx, 16
  59.       mov  bl, dh
  60.       mov  al, [bx]
  61.       add  edx, esi
  62.       mov  ebx, edx
  63.       shr  ebx, 16
  64.       mov  bl, dh
  65.       mov  ah, [bx]
  66.       stosw
  67.       dec  cx
  68.       jnz  @1
  69.       pop  ds
  70.     END;
  71.     Inc(PosX, IncY);
  72.     Inc(PosY, -IncX);
  73.   END;
  74. END;
  75.  
  76. {
  77. as you can see, very methodical coding, but it's quite fast, and does the
  78. job....
  79.  
  80. >> It was coded before 2nd reality was released, but didn't get released
  81. >> till after because of distribution problems..
  82.  
  83. > Second Reality was ok, but they coulda done better. I did like the
  84. > bubbling landscape demo (voxel stuff)
  85.  
  86. try, although i was disappointed that they didn't really do much new (those
  87. blue bolls were nice though, although they flickered quite alot.. but hey! i'm
  88. hardly paying for the demo, am i!)
  89.  
  90. but yeah, the voxel stuff was nice.. after reciving email from Lord Logics (of
  91. Avalanche), he says that he's been working on some voxel stuff, although he
  92. didn't get it finished because of getting a job, although he intends to finish
  93. it and release it in a demo for avalanche.. so that'd be nice to see..
  94.  
  95. tell me if the code is efficent or not! :-)
  96. }
  97.  
  98. (*
  99. SEAN PALMER
  100.  
  101. > yes i realize it works out real nice with 256x256 bitmaps, because you
  102. > can shift/carry or whatever to get the particular point in the
  103. > bitmap you want easily.
  104.  
  105. No, you don't have to do diddly squat to extract it. Just move the byte out.
  106. Since one's in the hi byte of a 32-bit register though, it's harder to extract.
  107.  
  108. > yes it uses 32 bit instructions, but since it's so short, it's not a
  109. > problem coding it in BASM.. and here it is:
  110.  
  111. Of course you know that BP 7.0 won't do 386 instructions. So this wouldn't
  112. compile as is. Needs a lot of DB $66's, etc.
  113.  
  114. > ** this code was written by The Faker of Aardvark **
  115.  
  116. Hi Faker! Sorry to botch your code below. 8)
  117.  
  118. > PROCEDURE PutTexture(IncX,IncY:Integer; P:Pointer);
  119. > VAR
  120. > Y,PosX,PosY,PX,PY:Integer;
  121. > BEGIN
  122. > PosX:=-(ScreenX SHR 1)*IncX;   { ScreenX,-Y are size of screen}
  123. > PosY:=-(ScreenY SHR 1)*IncY;   { PosX,y set so rotation is around}
  124. > FOR Y:=0 TO ScreenY-1 DO       { the middle (of 'p')}
  125. > BEGIN
  126. > PX:=PosX;   { PosX,-Y is updated every line, PX,-y derived}
  127. > PY:=PosY;
  128. > ASM
  129. > push ds
  130. > mov ax,0a000h
  131. > mov es,ax
  132. > mov ax,y
  133.      shl ax,8    {this is same speed, but cleaner}
  134. > mov di,ax      {lessee... ends up y*320. Faster than MUL. But should}
  135. > shr di,2       {be incrementally calculated instead.}
  136. > add di,ax
  137. > lds si,p       { in P there should be a 256x256 bitmap }
  138. > mov cx,screenx shr 1
  139. > cld
  140.                         {cleaned out the intermediate use of eax}
  141.      mov si,incx
  142.      shl esi,16
  143.      mov si,incy
  144. > mov dx,px
  145. > shl edx,16
  146. > mov dx,py
  147. > @1: add edx,esi
  148.      shld ebx,edx,16    {do move and shift all at once. Save 2 cycles}
  149. > mov bl,dh
  150. > mov al,[bx]
  151. > add edx,esi
  152.      shld ebx,edx,16    {ditto. I like this unrolled loop! 8) }
  153. > mov bl,dh
  154. > mov ah,[bx]
  155. > stosw              {word access. Sweet.}
  156. > dec cx             {better than LOOP on a 386+}
  157. > jnz @1
  158. > pop ds
  159. > END;
  160. > Inc(PosX,IncY);
  161.      Dec(PosY,IncX);    {avoid neg operation}
  162. > END;
  163. > END;
  164.  
  165. > as you can see, very methodical coding, but it's quite fast, and does
  166. > the job....
  167.  
  168. Yep. I haven't coded it up where it'll compile and run it yet, but Should Be
  169. Pretty Darn Quick. Seems like it's gonna have a problem with the carry from dx
  170. to the hi word of edx (your position will be off, barely, every time it
  171. wraps.... shouldn't matter much)
  172.  
  173. > but yeah, the voxel stuff was nice.. after reciving email from Lord
  174. > Logics (of Avalanche), he says that he's been working on some
  175. > voxel stuff, although he didn't get it finished because of
  176. > getting a job, although he intends to finish it and release it
  177. > in a demo for avalanche.. so that'd be nice to see..
  178.  
  179. I'm gonna have to code something like that up for a BattleTech type game. Best
  180. idea I've seen so far for terrain... If you see any code to get me started,
  181. please route it my way.
  182.  
  183. > tell me if the code is efficent or not! :-)
  184.  
  185. Only one optimization I can spot right now (aside from coding the outer loop in
  186. ASM as well...) Is that he has to shift the 32-bit registers around to get at
  187. the upper word. (the 386 needs more data registers!!!!!! ARE YOU LISTENING
  188. INTEL!!!) So using the SHLD instruction like I re-coded above should speed it
  189. up some. Avoid the intermediate register move.
  190.  
  191. I've commented above. You could put alot of the setup stuff outside the loop if
  192. you wrote it all in BASM. Wouldn't have to push/pop for each scan line, etc.
  193. But that's a minor speedup.
  194.  
  195. In the future, try to gain access to the FIDO 80XXX echo. It's a much better
  196. place to talk about (mostly) assembly stuff.
  197.  
  198. *)